Since Release being called could be for other reasons besides this one particular case ...

My first thought - before further analysing the BlueZ source code - was that even though the Release is called for other reasons, it shall for sure not be called before this function returns.

Checking the source https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/adv_monitor.c#n520, I see that D-Bus Release method is invoked only from monitor_release(), which is called only from monitor_destroy(), which is called from 5 functions, all of them related to removal of the monitor as a result of deliberate action, error, or invalid parameters.

... maybe it is better to just stick with the os.uname() check and fail early?

I like the os.uname() idea, but would prefer to solve this as BlueZ-ish as possible - maybe someone can use a custom kernel or kernel patched to have or have not support for this feature... Most probably not, but still - this was a fun/frustrating challenge for today.

Done some more testing, using kernel <5.10 and >5.10.

In case of kernel <5.10, Release() is invoked during the call of SupportedFeatures(), as expected.

In case of kernel >5.10, Activate() is called some time after this function already returns - e.g. if using:

async with BleakScanner(..., scanning_mode="passive"):
    await asyncio.sleep(0.0001)

no AdvertisementMonitor method is invoked, but when this delay is increased, Activate() is invoked. Interestingly, Release() is not invoked at all, even if I add some sleep after the context manager.

I added example file: On one hand, I like to show how one can use async iterator to print detected devices, but on the other hand, it gets complicated. I can remove or simplify it if you prefer, I'll do PR for BleakScanner supporting async iteration anyway. it tries to use the passive scanning first and falls back to active scanning if not possible.

The scope of this PR is creeping. Can we please stick to just one change at a time?

Regarding checking if Release has been called or not, I've thought about it a bit more and it seems like we should make this cancel any async task in the async context manager and raise an exception similar to how asyncio.timeout works. This would avoid any race condition of when Release is called and we wouldn't have to rely on the hack of getting a property to get the right timing and would also cover any other reason for Release being called at any time.

but would prefer to solve this as BlueZ-ish as possible

This seems like it would require a change to BlueZ, such as exposing a list of supported management APIs. Since Release can be called for multiple reasons, it doesn't seem like a reliable solution for detecting support of passive scanning (but it still does seem worth handling the call to Release since we have seen that not handling can lead to waiting for advertisements that will never come).

I'll wait for #1146 and #1147 to be merged and then rebase using features from #1146.

Rebased on #1146.

Based on the BlueZ tests, it seems like Release() being invoked for failed registration of the monitor is expected behaviour.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-adv-monitor#n328

    # Register the app root path to expose advertisement monitors.
    # Release() should get called on monitor0 - incorrect monitor type.
    # Activate() should get called on monitor1.
    ret = app.register_app()
    if not ret:
        print('RegisterMonitor failed.')
        mainloop.quit()
        exit(-1)

After further checking BlueZ sources and tests, I used the fact that either Activate or Release will be invoked when the advertisement monitor is processed and came up with the current implementation.
One additional benefit of this implementation is that when BleakScanner.start() returns, we are sure that the passive scanning has actually been started (or failed).

As the latest solution does not really use features from #1146, except adding a comment explaining why callback is not added to _discovery_stopped_callbacks when passive scanning

BlueZManager -> async passive_scan() -> async with self._bus_lock:
            self._device_removed_callbacks.append(device_removed_callback_and_state)

            # Once a monitoring job is activated by BlueZ, the client can expect to get notified
            # on the targeted advertisements no matter if there is an ongoing discovery session
            # (started/stopped with org.bluez.Adapter1.StartDiscovery/StopDiscovery, as done when
            # using active scanning).
            # That is why discovery_stopped_callback is not added to self._discovery_stopped_callbacks
            # at this point, as org.bluez.Adapter1.Discovering status is not relevant for passive
            # scanning.

            # If advertisement monitor is released before the scanning is stopped, it means that the

I've moved it to bojanpotocnik:1136_verify_adding_adv_monitor_rebased_1146 and rebased this one on develop.